\section{Comparación de Metodologías}
\subsection{Programming in the small Vs Programming in the large}
Ahora que hemos trabajado de ambas formas nos damos cuenta que realmente programming in the large para la primer parte del tp era impensable, porque conceptos como análisis de riesgos o hitos se desdibujan cuando tenemos que hacer algo tan acotado y pequeño.

Cuando nos tocó realizar el diseño de objetos teníamos un alcance bien claro y definido y pudimos dividirnos bien las tareas para llevarlas a cabo y todo fue bastante informal, no teníamos un project ni nada parecido, íbamos tomando las tareas pendientes a medida que nos desocupábamos. Para esta segunda parte no tuvimos que realizar implementación, pero hemos estado mucho tiempo con el tema del diseño de arquitectura, no sólo eso, nos costó mucho decidirnos por los atributos de calidad, sobre todos los planteados en la reunión con los stakeholders, porque a algunos les parecía importantes unos atributos a otros, otros diferentes. En un punto, tanta información e incertidumbre nos pasó por arriba, luego pudimos ir desmenuzando las cosas y sacando ideas un poco mas claras, pero esto llevó su tiempo.

Respecto al manejo de la cantidad de gente, si bien no hemos sufrido variaciones, lo cual no nos deja comparar cómo es trabajar en grupos de 5 personas vs grupos de 100, si podemos decir que ponernos de acuerdo en la parte de arquitectura nos costó muchísimo mas que cuando discutimos el diseño de objetos, quizás porque es algo mucho mas amplio, que abarca muchas mas cosas, hay que pensar cómo comunicarse con miles de componentes, muchas veces desconociendo cómo funcionan, evaluando qué pasa si andan lento o se caen, etc. Cuando uno discute el Diseño de Objetos, está centrado en algo mas tangible y, por lo general, mas acotado. 

Ya lo decía Brooks: "`La arquitectura debe ser producto de un único arquitecto o un pequeño grupo de arquitectos con un claro líder"' y realmente se notó, porque la cantidad de horas que nos pasamos discutiendo una simple cosa o convenciéndonos los unos a los otros de ir por un camino. El esfuerzo se hubiese reducido mucho con un único arquitecto o alguien que toma decisiones, porque opciones hay muchas y lo difícil no es plantearlas sino decidirse por una sola.

\subsection{Scrum Vs UP}
Son dos metodologías que, si bien ambas tienen el concepto de lo iterativo incremental, son sustancialmente diferentes. Cuando usamos Scrum nos pasó había conceptos que ya traíamos nosotros de nuestra forma de trabajar y estimar que no teníamos en cuenta como por ejemplo el tema de las dependencias. En ese sentido, nos familiarizamos mas con UP que sí coteja las dependencias entre tareas.

Por otro lado, hay cosas de Scrum que no pudimos observar bien como serían porque no se veía lo más distintivo que tiene quizás, que es ese seguimiento diario sobre las tareas realizadas, aquellas que se han puesto mas difíciles de lo previsto, etc. Por lo cual, esa visión real diaria que uno podría tener del status del proyecto no pudimos apreciarla, pero aún así es algo que recalcamos de dicha metodología que no se observa tanto con UP por tratarse de una metodología orientada mas a grandes proyectos.

Respecto al seguimiento en UP, algo importante que tiene es el hecho de poder representar un cambio, como la enfermedad de un recurso o el atraso de una tarea, y ver, al modificar el gantt, que efecto tendremos en cuanto a tiempos de cumplimiento. Esto nos permite elaborar una estrategia para afrontar el imprevisto, como por ejemplo reasignar recursos, modificar ejecución de tareas, etc.

Además, nos permite visualizar fuertemente los hitos y los riesgos asociados a ellos, esto es algo que en Scrum ni se menciona, los riesgos de que no nos entreguen un dispositivo o bien se atrase un entregable o que la persona encargada de hacer algo muy específico no pueda concurrir, etc. Nosotros nos quedamos mucho mas tranquilos sabiendo que tenemos hecho un análisis de los riesgos que puedan ocurrir y que, en caso de que se manifiesten, no nos tomen por sorpresa sino que contamos con plan de contingencia para sobreponernos a la situación.

Algo que no nos gustó mucho de UP, es el hecho de priorizar las tareas más riesgosas, primero porque el riesgo no deja de ser una estimación entonces ahí ya introducimos un error por estimación. Pero más allá de eso, hay tareas que se tornan muy riesgosas porque no están bien definidas por el usuario o bien porque nos piden usar una tecnología desconocida para nosotros y luego resulta que cuando la aprendemos era algo que costaba poco esfuerzo o era relativamente fácil de realizar. 

Lo que queremos decir con esto es que, la forma "`greedy"' que tiene UP de seleccionar los casos de uso mas riesgosos para realizar en las primeras iteraciones, no siempre nos cerró, de hecho, hemos dejado afuera de nuestra primer iteración casos de uso donde el riesgo provenía de que el usuario no sabía muy bien que quería cuando lo planteó o no conocía el alcance del mismo entonces se tornaba altamente riesgoso. Lo que queremos decir con esto, es que no hay que elegir los casos de uso a ciegas por el riesgo que conllevan sino tener sentido común a la hora de evaluar los que haremos en cada iteración.

Algo que comparten ambas metodologías, es el aprendizaje a la hora de estimar tareas: uno al comienzo estima sin conocer demasiado al equipo asignado, sus cualidades, a veces no se conoce realmente el esfuerzo de una tarea simplemente porque no conocemos la complejidad del dominio del problema, pero creemos que eso es algo que va más allá de la metodología con la que estemos trabajando, sino que tiene que ver con el arte de estimar, que ya es muy complejo en si mismo. Creemos que cuando se consolida un grupo de trabajo y se conoce un poco mas sobre el dominio del problema, las estimaciones se tornan un poco mas reales que las iniciales.
